Implementing Reliability: The Interaction of Requirements, Tactics and Architecture Patterns

An important way that the reliability of a software system is enhanced is through the implementation of specific run-time measures called runtime tactics. Because reliability is a system-wide property, tactic implementations affect the software structure and behavior at the system, or architectural level. For a given architecture, different tactics may be a better or worse fit for the architecture, depending on the requirements and how the architecture patterns used must change to accommodate the tactic: different tactics may be a better or worse fit for the architecture. We found three important factors that influence the implementation of reliability tactics. One is the nature of the tactic, which indicates whether the tactic influences all components of the architecture or just a subset of them. The second is the interaction between architecture patterns and tactics: specific tactics and patterns are inherently compatible or incompatible. The third is the reliability requirements which influence which tactics to use and where they should be implemented. Together, these factors affect how, where, and the difficulty of implementing reliability tactics. This information can be used by architects and developers to help make decisions about which patterns and tactics to use, and can also assist these users in learning what modifications and additions to the patterns are needed.</p

Variation in care in the management of children with Crohn's disease: Data from a multicenter inception cohort study

Background: Variation in care is common in medical practice. Reducing variation in care is shown to improve quality and increase favorable outcomes in chronic diseases. We sought to identify factors associated with variation in care in children with newly diagnosed Crohn's disease (CD). Methods: Prospectively collected data from a 28-site multicenter inception CD cohort were analyzed for variations in diagnostic modalities, treatment, and follow-up monitoring practices, along with complicated disease outcomes over 3 years in 1046 children. Generalized linear mixed effects models were used to investigate the intercenter variations in each outcome variable. Results: The mean age at diagnosis was 12 years, and 25.9% were nonwhite. The number of participants ranged from 5 to 112 per site. No variation existed in the initial diagnostic approach. When medication exposure was analyzed, steroid exposure varied from 28.6% to 96.9% (P 0.99). Use of immunomodulators (IMs) varied among centers both within 90 days (P < 0.01) and during 3 years of follow-up (P < 0.01). A significant variation was seen at the geographic level with follow-up small bowel imaging and colonoscopy surveillance after initial therapy. Conclusions: Intercenter variation in care was seen with the initial use of steroids and anti-TNF, but there was no difference in total 3-year exposure to these drugs. Variation in the initiation and long-term use of IMs was significant among sites, but further research with objective measures is needed to explain this variation of care. Small bowel imaging or repeat colonoscopy in CD patients was not uniformly performed across sites. As our data show the widespread existence of variation in care and disease monitoring at geographic levels among pediatric CD patients, future implementation of various practice strategies may help reduce the variation in care

Automated Selection of Software Components Based on Cost/Reliability Tradeoff

Abstract. Functional criteria often drive the component selection in the assem-bly of a software system. Minimal distance strategies are frequently adopted to select the components that require minimal adaptation effort. This type of approach hides to developers the non-functional characteristics of components, although they may play a crucial role to meet the system specifications. In this paper we introduce the CODER framework, based on an optimization model, that supports “build-or-buy ” decisions in selecting components. The selection crite-rion is based on cost minimization of the whole assembly subject to constraints on system reliability and delivery time. The CODER framework is composed by: an UML case tool, a model builder, and a model solver. The output of CODER indicates the components to buy and the ones to build, and the amount of testing to be performed on the latter in order to achieve the desired level of reliability.

Architectural Description of Dependable Software Systems

Architectural description languages (ADLs) are used within the software engineering community to support the description of high-level structure, or architecture, of software systems. A major advantage of this is the ability to analyze and evaluate trade-off among alternative solutions. This chapter will discuss the role of ADLs for representing and analyzing the architecture of software systems. Since ADLs vary considerably on the modeling aspects that they cover, we will focus our discussions on how ADLs support structuring dependability issues